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Serial No.: 09/823,581 
Respond to OA of 11/23/05 

Remarks 

According to 37 CFR LI 05, Applicants and assignee provide the following 
information that the Examiner has determined is reasonably necessary to the examination 
of this application. Applicants respond as fellows: 

• Request: The Examiner requests copies of two cited references C 'Inter-Enterprise 
Collaborative Business Process Management" and "How Agents from Different E- 
commerce Enterprises Cooperate"), 

o Response: Applicants submit herewith copies of the references. 

• Request! The Examiner requests a concise explanation of the reliance placed on the 
two cited references. 

o Response: The references formed part of the invention disclosure for the 
present application. 

• Request: The Examiner requests clarification as to the inventorship of the instant 
application and the two cited references. 

o Response: Mr. Igor Kleyner is named as an author on one of the cited 
references ("How Agents from Different E-commerce Enterprises 
Cooperate*'). The contribution of Mr. Igor Kleyner to this article, 
however, was not sufficient to warrant naming Mr. Igor Kleyner as an 
inventor of the instant application. 

• Request: The Examiner requests names of any products or services that have 
incorporated the claimed subject matter. 

o Response; Hewlett-Packard Co, is not currently utilizing this technology 
in a marketed product. A third-party company (Commerce One) may have 
implemented, subsequent to the filing of this application, a portion of this 
technology in a product named "Conductor." 
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Response to OA of 1 1/23/05 

• Request: The Examiner requests specific improvements of the claimed subject matter 
over the two cited references. 

o Response: Applicants do not believe that the two cited references 
constitute prior art since these references formed part of the invention 
disclosure. 

• Request: The Bxaminer requests citations and copies of any publication that 
Applicants authored or co-authored describing the disclosed subject matter. 

o Response: Applicants are not aware of any material prior art references 
that are not of record. 

• Request: The Examiner requests citations and copies of any publication that 
Applicants relied on to develop the disclosed subject matter. 

o Response : Applicants are not aware of any material prior art references 
that are not of record. 

Applicants believe that this response complies with the requirements of good faith 
according to 37 CFR 1,56. 



Respectful 




Philip S, Lyr< 
Reg. No. 40,709 
Ph: 281-514-8236 



CERTrPTCATE UNDER 37 g,F_a 1 
THe undersigned hereby certifies tiiat this paper or papers, as desciibedAerein, is being transmitted to the United States 
Patent and Trademark Office fecaimile number 57 1 -273-830 0 on this «Sp day of December, 2005 

Name: CameMcKsrley 
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cooperative Conventional workflow systems are primarily designed for irtira-enterprtee 

process process management, and they are hardly used to handle processes with 

management **** and ***** separated by enterprise boundaries, for reasons such aa 

security, privacy, fiharahUity, firewalls, etc. Further the cooperation of 
multiple enterprises is often baeed on peer-to-peer interaction* rather than 
centralized coordination. Aa a result, the conventional centralized process 
management architecture does not fit into the picture of inter-enterprise 
buainefia-to-businesa E -Commerce. 

We have developed a Collaborative Process Manager (OPM) to support 
decentralized, peer- to- peer process management for inter-enterprise 
collaboration at the business process level. A collaborative process is not 
handled by a centralised workflow engine, but by multiple CPMs, each 
rep res en te a player in the business process. Each CPM is used to schedule, 
dispatch and control the tasks of the process that the player is responsible 
for, and the CPMs interoperate through an inter -CPM messaging protocol 
An XML based Collaborative Process Definition Language, CPEL, extending 
the process definition language (PDI,), is developed for specifying 
collaborative buaineas processes. We have implemented CPM and embedded 
it into a dynamic software agent architecture, E-Carry, that we developed at 
HP Labs, to elevate multi-agent cooperation from the conversation level to 
the process level tor mediating B-CommercB applications. We have also 
integrated E-Caxry with E-Speak, an inter-enterpria* communication 
infrastructure product developed at HP, 

In general, our approach represents a shift from centralized process 
management to decentralized, collaborative process management, We 
believe that CPMs will be the basic building blocks for a scalable, dynamic, 
inter-enter prise middleware framework. The feasibility and practical value 
of this approach have been demonstrated by the prototypes implemented at 
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Abstrac t 



Conventional workflow systems are primarily designed for mtra-enterprise process management, and 
they are hardly used to handle processes with tasks and data separated by enterprise boundaries for 
reasons such as security, privacy, stability, firewalls, etc. Further the cooperation of multiple 
enterprises is often baaed on peer-to-peer interactions rather than centralized coordination. As a result tho 
conventional centralized process management architecture does not fit into the picture of inter-en tcmrise 
business-to-business E-Commerce. * 



We have developed a Collaborative Process Manager (CPM) to support decentralized, peer~to-peer 
process management for Inter-enterprise collaboration at the business process level. A collaborative 
process is not handled by a centralized workflow engine, but by multiple CPMs, each represents a player 
in the business process. Each CPM is used to schedule, dispatch and control the tasks of the process Oat 
S #?" Be Jf ^°? sibl 5 *• CPMt intemperate through an inter-CPM messaging protocol. An 

ht ^^Uobara&ve Process Definition Language, CPDL, extending the process definition 
langroge (PDL) « developed for specifying collaborative business processes. We have implemented 
t,PM and embedded tt into a dynamic software agent architecture, E-Cany, that we developed at HP 
Labs, to elevate multi-agent cooperation from the conversation level to the process level for mediating B- 
Commerce applications. We have also integrated E-Carry with RSpeak, an uiter-entarprise 
communication mlrastiuctare product developed at HP. 

In general, our approach represents a shift from centralized process management to decentralized, 
collaborative process nuuuujement We believe that CPMs will be the basic building blocks for a scalable, 
dynamic, inter-enterpnse middleware framework. The feasibility and practical value of this approach 
nave been demonstrated by the prototypes implemented at HP Labs. 



1. Introduction 



E-Commerce appUcattons operate in a distributed environment involving multiple parlies with 
dynamic availability, and a large number of heterogeneous information sources with evolving 
contents. A business partnership is often created dynamically and maintained only for the 
required duration such as a single transaction. E-commerce activities typically rely on business- 
to-business (B2B) and buaicess-to-consumer (B2C) irxteroperation at the business process level. 
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The automation of these activities represents both challenges and opportunities for supportms 
mter-enterprise business process management 

1.1 The Problem 

The general function of a workflow engine is to support the modeling and execution of business 
processes [34}. Although the tasks that contribute to a process can be distributed, they are 
centrally scheduled at the process level. Such centralised process control is appropriate for a 
single enterprise. However, intra-enterprise process management and inter-enterprise process 
management are significantly different When multiple parties belonging to different enterprises, 
are involved in a business process, they are unlikely to use a centralized process management, 
because they are often separated by firewalls, have self-interests, and do not wish to share all the 
process data. Rather, they need support for peer-to-peer interactions. This has become the major 
impendence for using the conventional centralized workflow systems for mter-enterprise E- 
Commerce automation. In fact, to our knowledge, there has been no such experience reported. 

1.1 TheSolutfm. 

i * 

Our solution to the above problem is based on extending process management from the one- 
server model to the multi-server peer-to-peer model, a shift from centralized process 
management to collaborative process management. 

We intone the notion of a collaborative business process (Figure 1). A collaborative process 
involves multiple parties. The process definition is based on a commonly agreed operational 
protocol, such as the protocol for on-line purchase or auction. A collaborative process is not 
executed by a centralized workflow engine, but by multiple engines collaboratively. More 
exaouy, each execution of a collaborative process, or a logical process instance, consists of a set 
of peer process instances run by the Collaborative Process Managers (CPMs) of participating 
parties. These peer instances share the same process definition, but may have private process 
data end sub-processes. The CPMs run these peer instances independently and collaboratively 
The CPM of each party is used to schedule, dispatch and control the tasks that party is 
responsible for, and the CPMs interoperate through an inter-CPM messaging protocol to 
synchronize their progress in process execution. An XML[2J-based Collaborative Process 
Definition Language, CPDL, extending the process definition language (PDL), is developed for 
specifying collaborative business processes. Solutions for synchronizing collaborative process 
execution are developed. 

For example, in case a buyer wants to buy something from a seller, the buyer-side CPM engine, 
A, creates a logical instance of the purchasing process, and initiates a "buyer-side" peer instance- 
A then notifies the seller-side CPM, B, to instantiate a "seller-side" peer instance of the purchase 
process. The peer process instances at both sides can be considered as autonomous but are 
following a purchase protocol both the buyer and the seller are willing to comply. When A 
finishes a task, it informs B of the task status, in order for B to proceed, and vice versa. The 
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entire purchase process is not handled by any common server, but by the peer-to-peer 
cooperation of multiple servers. 




Collaborative process d nfimti ™ 



Peer process instance um by A 




PetrjuDcws instance ronbyB 




Collaborative proem manager A. 

Enterprise ] .. _ _ 




ColUbontlve proceH manigsr B 

Enterprise 2 




Figure 1: Peer-to-peer collaborative process management 

Further, we integrate collaborative process management wife an agent infrastructure, E-Cany, 
that we have developed at HP Labs. We show how agent-embedded CPMs can be used to shift 
agent cooperation from the agent conversation level to the process level, while at the same time 
shifting workflow management from centralized process management to collaborative process 
management We have developed prototypes at HP Labs to illustrate the feasibility and practical 
value of the proposed approaches for enabling agent-mediated E-Commerce. 

We claim that the proposed collaborative process management can provide a significant 
extension to the current workflow technology, ft enhances the interaction of dynamically formed 
business partnerships, allows us to support inter-enterprise business cooperation at the process 
level, and represents a step towards a dynamic distributed middleware infrastructure. 

Section 2 compares collaborative process management with other workflow schemes. In Section 
3 the collaborative process model is described. Section 4 discusses the execution issues of 
collaborative processes. Section 5 describes the integration ofCPM with an agent architecture, 
and illustrates the use of CPMs to support multi-agent cooperation. Some concluding remarks are 
given in Section 6. 



2. From CenrrnH 




ent 



2.1 Cenfa-flHTftri P^ycoM Management 



Workflow servers are used to coordinate the execution of multiple actions that form a business 
process [13,14,25,34]. A business process specifies the integration and synchronization of multiple 
stqis, each step represents a logical piece of work, or action, that contributes to the 
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accomphshment of the whole process. Although these actions and the agents executing the 
actions ^ can be distributed, they are scheduled and coordinated by a centered workfl™ Line 
and SKI* T P ^ eSS * Glude8 8 containing L process 

So^ Fi^ ^ Pr ° CeSS stote ^ updating these data. Howeve^s 

^ m Fl 8«« 2, consider a purchase process involving tasks belonging to different 
enterprises, e.g. the buyer and the seller. It is unrealistic to have the buyer and the seller 

STn^otia^SflS 1 ^ " d * * ■»"«■«*"• for them to put their private data 

(e.g. negotiation threshold) into the common process data packet for flow camel 

El^iMMB Caxtz ^ Uztd Workflow en&mn 

Baglnesa process 




'fx?. 



figure 2: Centralized wortyovr control: not fin- cross-enterprise applicant* 




as 



2J2 Snhpr ocera Eygpirtrttn 

A teak belonging to abusiness process, say/', may itself be a process, />', referred to as a 
subprocesBof/»[34l (Figure 3). When P ' is bound to /> at the process definition phase ^ ' 
EJUS S T hC < ? Uen f )n . of * When P' is bound to P at the process execution phase, P ' 
becomes a dynamic extension of P. In any case P' inherits some property, including the 

(t ^? J ^> ? fthe P^. 0 ^ 8 *«» * ^ving its own specialized properties 
and data. As P is just the extension of P. they are typically executed in the same enterprise 



process P 




rab-pflBCHsP' 

Figure 3: A tub-process executed In the tame enterprise as the parent process 
12 Multf-processea Intel- operation, or Federation 

Multiple individual business processes maybe executed concurrently but with interoperability 
for example, two processes, say P, and P h may interoperate in the following ways 

• Some tasks of Pj and P 3 have operational dependencies. For example, task T, of depends 
on the termination of task T, ofP 2 to start, such that T, cannot start until Tj terminates (Figure 

• Pi and P 3 exchange data at certain steps. 

The Workflow Coalition (WfC) published recommended interface specifications for process 
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interoperation. 

ProeetaPl 




Process P2 

Figure 4: Inter-operation of different pro cesses 

It is worth, noting the following features of the conventional process interoperation, in order to 
distinguish it from our proposed collaborative process management. 

• The conventional process interoperation, or federation, primarily focuses on intra-enterprisc 
applications. It lacks support for inter-enterprise cooperation. 

* ^conventional notion of process interoperation deals with the relationships between 
different processes. Although these processes may runontha same or different workflow 
engines, each process is fully executed by that engine. For each individual process, besides 
certain dependencies with others, the whole flow control is based on its own logic and 
execution progress. 

2.4 Transaction Grq^p 

Several advanced models on transaction groups and cooperative transactions were reported in 
[3,7-11 ,i9^l^M234]. These models are characterized by joint execution of a transaction by 
rmUGple participants, and applied to such applications as cooperative design. The obvious 
difference of our approach from the above efforts is that we tackle the peer-to-peer interaction 
where no joint task is involved. We focus on inter-enterprise applications where partidpating 
parties, such as a buyer and a seller, deal with each other but have their own private database and 
decision rules. 



2.5 Partner Interface Progeny fl^^p^ 




Figure S: Partner Interface Process (Rosetta-net) 

The RosettaNet Consortium, founded in 1998, has placed focus on defining standard interfaces 
between partners for business process integration pi]. More specifically, the consortium is 
dnving the development of Parmer Interface Processes (PlPs) that define the processes and data 
elements necessary for a broad set of supply chain scenarios. The PEPs only define the 
"interface" tasks mat supply chain partners commonly participate in, but not the internal, 
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SZS^/^f v 8 USed by my partner to ^ businesses. It is the responsibility of each 
5KT£f£I?S ^ processes and s >' st6ms align to the PIPs. This concept is 

The PIP approach does address the issue of inter- enterprise process integration for enabling plug- 
StSSLS ne YPfaerc supply chain. However, the PIP specifications focus pEily 

on arcbitecting the information to be exchanged at the connection points of partner businesT 
processes; they do not focus on a common process-level specification for ail the partners 
Further, the PIPs do not offer a model of execution; far instance, k does not intend to specify 
now tne partner process instances are synchronized, or made to be aware of the progress of the 
peer processes. The CPM approach discussed in this paper am be used to support MPs We can 
convert PIPs into process definitions in CPM, and support their execution. 

The proposed peer-to-peer collaborative process management is different from all the above 
approves With this approach, an inter-enterprise business process is offered a global view, but 
executed by mulhple distributed CPMs of the participating parties. An uiter-enternrise 
collaborative process is defined based on the corresponding business protocols, and such a 
defininon becomes the common template for all the participating parties to share. However, an 
execution of a collaborative process, viewed as a logical instance of the process, actually 

™5 P P"* *»t ms not ™ut«d ^ a centralized workflow engine but by 

multrple CPMs and synchronized through peer-to-peer communication. The CPM at each side 
recognizes hs own share of the tasks (shaded in Figure 6) based on role-matching. For example 
an on-line trading process, say P, is executed collaboratively by a seller and a buyer in such a ' 
way that each peer CPM runs an individual process instance of P. For the CPM at buyer side, it 
is only responsible for (schedule and dispatch) me tasks to be executed by the buyer, such as 
preparing a purchase order and making a payment. Similarly the CPM at seller side is only 
responsible for the tasks belonging to the seller. The CPMs exchange task execution status 
messages tor synchronization. 




Figure 6: Logical view to the execution of an inter-enterprise collaborative process 

Compared with the conventional workflow and sub-process handling techniques, this approach 
differs in that it uses decentralized and collaborative process management. Note that here the 
decentralization is introduced to the process management level rather than the task execution 
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level. 



The conventional process mteroperation, or ft deration, approach, which supports task 
dependency enforcement and process data exchange, does not address many inter-enterprise 
cooperation issues. Also, the concurrently executed process instances do not follow die same 
process definition based on commonly agreed business protocols. Compared with that, the 
proposed collaborative process management has a clear focus and systematic support on protocol 
based inter-enterprise process management 

We share the same motivation as RosettaNet PIP approach in inter-eaterprise process integration, 
and we conclude that our approach is capable of supporting PIPs. However, our approach goes 
beyond PIP in the following aspects. 

■ First, collaborative process management is based on process-level business protocols. Given 
a collaborative process, P, although, each party is only responsible for a few steps of P t it can 
nave a global view to the whole business process from the shared process definition. On the 
other hand, the PIP approach is Interface based. PIPs expose individual "hand-shake" or 
conversation points of partner processes, but not a process level view to their cooperation 
Tae PIP approach can be more appropriately viewed as a design at the conversation level 
than at the process-level. 

■ Second, we have developed peer-to-peer execution mechanism for collaborative processes 
As mentioned above, each execution of a collaborative process consists of logically related 
process instances, for which we provide an execution model. In the PIP approach, however 
there is no corresponding execution model. The execution of partner processes are not related 
and synchronized at process-level. Each party sees the trees, not the forest 

From the above comparison we can see the uniqueness of the proposed approach in supporting 
peer-to-peer collaborative processes. 

3. Collaborative Pr ocess Definition 

To explain how the proposed collaborative process management approach extends the current 
workflo w technology, we adopt the usual concepts of business process modeling in the following 
discussions. A process is modeled as a DAG with nodes representing the steps, or tasks, and arcs 
representing the links of those steps. A work-node represents a step (task) and associated with an 
activity, i.e. a piece of work that contributes to the accomplishment of the process, that maybe 
executed either by a program (e.g. a software agent) or by a human worker. A process is 
associated with a packet of process data. When an activity is launched, a subset of the process 
data, sub-packet, is passed to it; when it is completed, together with task status information, the 
sub-packet, possibly updated during the task execution, is sent back for reconciliation with the 
process data packet. A route-node specifies the roles and conditions for flow control, process 
data update, etc. Conventionally, a process execution creates a single process instance. However, 
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St^^S 8 ^ft?t l0gical ***** L ° f ***** «™»Wo P«r process 

instances. Further, a collaborative process may have multiple concurrent executions: 

foUoS* COlkborative Processes, the minimal extensions to process definition include lie 

* e^S^ST*' h f 6 Hst ^ P^s-roles, indicating the logical participants. For 
example, if a simple purchase process has two roles, "buyer" and "seller", then there are two 

?n^S S l5- C ?K mV0 ^ m ltS e * ecnrion > 0ne at * e CPM for "buyer" and another at the CPM 
lor seller These two peer mstances are assigned roles "buyer" and "seller" respectively 

* A work-node has a task-role, and that must match one of the process-roles. In the above ' 

SSJt?^ TOk ? y*™" "? Kthe role task is "buyer", it is only 

executed in the peer process instance with process-role "buyer". 

Note that an activity also has a role called activlty-rde, such as "invoice-generator" 
meaning that this task should be executed by (or dispatched to) an agent playin* the ' 
^voice-generator" role in this process. The notion of activity-role can be found in regular 
business process specifications. * 

* ^f t H r r nte ^ I S e ^ 0lIab0ra ^ Ve proCess "ecuhon* each parly wants to keep some of the 
process data prviate. For example, me buyer in one enterprise and the seller m another 
enterprise do not want to expose their thresholds during price negotiation. In the process 
defimhoMewplntes for holding the definitions and initial values of process data objects can 
be specified. Further^ the sharing scope of the data objects is specified. A template may 
^public, i.e. sharable by all process-roles (and thus by all peer process instances) or 
process-role specific. A role- specific template is used by the peer process instances of me 
given roles (one or more) only, and such templates can be made different for different 
process-roles. Consider a collaborative process with roles "buyer", "seller" and "bank"- some 

ttrl^l^f SOm<S arc , 3harabl ° * " buvw " are public to all 

three roles. The initial data packet of a peer process instance consists of the appropriate 

templates, where me sharing scope of each data object is marked. This data packet can be 
updated or expanded at run time/ 

Let us use a simple example for explanation purpose. The sample collaborative process for on- 
line purchase defined based on the OBI (Open Buying on Internet) protocol, obCprocess, has 
process-roles ••buyer" and "seller". Each logical instance ot obijtrocess has twopeer-instances 
runat two peer CPM*, A and B, one at the buyer side and one at the seller side. It has several 
tasks (steps) mcludmg T, (make purchase order), T 3 (process purchase order), etc. T, is a step the 
buyer is responsib e fo, t n ha role is "buyer", while the role of 7} is "seller" A, running thTpeer 
mrtance wi&role ''buyer", is responsible for excuting T h and* running the peer instance wAh 
the role seller" , is responsible for executing T 2 . The initial data packet for process-role "buyer" 
^eludes templates obijpl and obi_puyer_tpl, while the initial data packet for process-role 
^sener* includes template obi_jpl and obi_sellerutpl. The activity «Action2 has an activity role 
order examiner' , and thus it is dispatched to an agent with activity-role "order examiner" for 

execution 



'toZHl JT ^ d ° a ° t ,^ licit i, y eddr * M * e sltuation 8 single process role is played by multiple players (as 

nt^S^^S^ ^J^j^y^ prOCeSS >- Su <* a axtLiomto both™ 

process definition and proccs a execution described in this pap— 
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Th© specification of this process is illustrated below. It ia WFC (Workflow Coalition [34]) 
standard compliant but is in XML format. When compiled, it is first translated into a DOM 
pocument Object Model) [15] tree of Java objects, then into a Java class for cooperative process 



■OttOCHSSatm^-OBUROCBSS" 

<ROL£S> Scliw, Buyer <BOLKS> 

<R0LE> Buyw </ROLE> 

<DESO Mike PwcbaseOider </DBSO 

<ACTwrn> Actioni ^activity* 

<WDRKJ*0DE> 



<WORKJ«>DB 

<ROLS> Seller */ROLZ> 

<DBSO Pmpcosa PorchA*<fedeT <DESO 

<ACTIVJTy> Actioo2 </ACTTVlTY> 

</WOHK ta N01>E> 



<ARC xwme^Arcl" type^FORWARD^ <FROM>Wa*N«§cl </FROM> <IT> Wo*NorM</TO> <ARO 



:FROCBS$^PATA> 

<TEMPLATE> GhjJn}</TEMPLATE> 
</PROCSSQJ2ATA> 

<PROCESSLpATA> 

<R0LE> Setter <fR01X> 

</PROCESSLtUTA> 

<»R0CES3_J>ATA> 

<R0LE> Huyec </RQLE> 

<TfiMPLATE* abi^i^etJpKnsMPLATB^ 
</PROCBSS_J3ATA> 
</FROC£SS> 

"^TEMPLATE nwno" t, abLKtle^q>l n > .„ </TEMPLATE> 
<TEMPLATE w U ne- , 'obUtoy*Upl'> M > <TBMPLATE> 

<ACTlVnT nm^»AG&na* type-TROCESS" imp-'AQENT^ 
<DESO Process punitaAe o»to </DESO 
<ROLB> ordar mminar -</ROI£> 
<CLA5S> PinsiiOTeOiteR*sult</CLASS* 
<JRI> ffie;cba^oom/«canyflCBLclaasea <URL> 
^ARQS> ♦„ </ARGS> 

<^Acnvrry> 



A task may represent a private sub-process with a private data packet. The sub-process binding is 
dynamic, that is, bound at run time. Thi$ allows a private sub-process to be designed separately 
from the host process (Figure 7). Furthermore, the process data of the internal sub-process is 
entirely pnvate to the party executing the sub-process. Below is an example. 



<ACT[V1TV Cflmo= ,, Acticai7 n typc^PROCESS" iaa^SUBPROC* 

<DESC> Check credit <DESC> 

<SUBPROO Cta£kLpredfU»oees» <75UBPROO 
</ACTrVlTY* 
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instances of csxnmum ! 
cooperative proocs; 




Figure 7: Handle enterprise internal activities and data by private tvbprocess 
4, Collaborative Pr ocess Execntfo ^ 

^SS^^^^ PI ^ 3S ° f a set ^P^Proces, instances run by the 

W^?f? e Pfti^P^g parties. These instances share (he same process definition butthey 
have additional properties and may have private process data and sub-processes, 

4.1 Cfol*bo<ratJve 

Each peer process instance has a role that must match one of the process-roles When SDH r 
process instance is launched by a CPM at the seller ««^T* a peer 

■b " D piw ™ j i^T^ ■, „ . seue ? 101 example, me proceas-mstance-role 

roleSer^ 18 7 rcSp ° nSible for Ruling and dispatclm^tasS^S! 

^SSTdSf hSSfS*™ ^^P™*^ player of each peer process instance must 
2? bound * ^ CI "Tesponding process instance role, m addition, a foetatf 

" w " ltal muat 156 ™«« pice* of taftnmte arSured as 

properties m every peer process instance. They are described below. P 

" S*L^ : fi illdic ^ the CPMs participating in the execution of a collaborative business 
process. A player is associated with four attributes ousiness 

° J^^tK^' ^y^'' ?f 4™ procea * ™ ia ™ at the CPM that 

rCTrcl^ P yCr ' to a P^^insto^ a CPM do« not have 

° I^^T*? fT* ; f d ™ n 13 a ^° U P of communicating servers coordinated by a awnflnafer 
server of that domain. The name of the domain is the name that the coordinator use^o rcSsS 

^rp%!Sm^ * y * XS * i *' *° ^^P^ of a *>™*» name can be 

° iSnS.XL 0 !' 11 ",^, 8 ™ ^ dMmin to r *» resettt P^- Ea^ server has a 
umc^elocal name within a domain. While a domain may have multiple CPM servers, one or 
more CPMs are selected to represent the players in this process instance. For eaarnpfc, 

SS? tfL %H? ^ a player playin » buyer role in a purchasing business 
process, Tvhosepeer CPM in this process might be vs.oracle.com/sales*j3gent. 
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□ The inter-domain messaging service infrastructure, such as HP E-Speak, that provides messaging 
services for inter-domain CPM communication. Th* messaging service infrastructure is capable 
of delivering messages among multiple domain* When inter-domain CPMs rely on E-Speak to 
reach each other, the addressing structure is 
espeak:dmnatoi m flame/locat m jtame* 
An example is espeakrcorp. hp.oom/buyin&jigent. More detailed message delivery mechanism 
will be explained later, 

• Coop-key: this is used to identify a logical instance of a collaborative process, lhat is, to 
correlate and synchronize the multiple peer instances of the execution of a single 
collaborative process. All the messages exchanged for that execution are marked by a unique 
coop-key. In our implementation, each CPM can run multiple process instances concurrently, 
and. each instance has a local ID. Each CPM engine maintains a mapping table between coop- 
keys and local process instance IDs. When a message relating to the execution of a 
collaborative process is received, the coop-key is used to identify the corresponding local 
process instance. 

As shown in Figure 8, when a collaborative process is defined, it is specified with the process- 
roles and task-roles. When a logical process instance is created, the players and the roles they 
play are specified. The CPM at the creating party obtains a coop-key for this logical process, 
creates a peer process instance for itself, and associates this key with its peer process instance 
When the CPM at the creating party sends requests to other peer CPMs (It., the other players of 
the process) to instantiate the peer process instances, the coop-key is also specified. This coop- 
key is encapsulated in all the messages on the above logical process instance, and transferred to 
all peer sides to correlate peer instances of the collaborative process execution. 

Define PiDcen 



nras 1 


Bmr ar. antisT J 


L maw 




r ^(^Miirm— 








"is* 











>cess Instance 


BoJm 


&nrn. ItHtr 


TOLA* 




WHJrlanUal. " 


ueit£# 


J 




**r 1 J 


rTtcouapjtict 1 DialuUeeB 1 



InrtBiitiftt* Ptt* Process Instances 





Jtonir i seller 








Srhr ' 








^JuBcvettDOB" 







Figure 8: Settings /or defining, creating and Initiating collaborative process 

Using the above obi^rocess as an example, the execution of a collaborative process is carried 
out in the following way: 

• CPM A, representing the process-instance-role of "buyer", initiates a buyer-side process 
instance P b and through messaging, tells CPM B to create a seUer^side peer process instance 

• A dispatches and executes T 2 > and upon receipt of the task return message, r h forwards it to 
all other players of the process, in this case, simply B. Both A and B update their process 
state and schedule the possible next step of their own peer process instance based on that 
message. 

• When A proceeds to activity 7>, since the role represented by A does not match the role of 
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T* A simply waits for the peer server, that is B in this example, to handle it at the peer site, 

• When B proceeds to activity T ?i since the role represented by 3 matches that of T>, 7% will 
be handled by 2?. 

• The execution of peer process instances at both peer CPMs progress in this way, towards 
their ends, 

4.2 Synchronizing Process Datft m d Data in the Task Ret»r ff M eSH a e ^ 

An activity is dispatched to a software agent or a human user to perform, and upon its 
termination, a task return message is sent back and used to trigger the next step in process 
execution, Such a task return message contains the following information: 

□ coop-key of the logical process instance, 

□ handles (local Ids) of the process instance, task, and activity, 

□ activity execution status, 

□ the sub-packet, Le. the subset of process data passed to the activity. 

When a task return message comes back to the local CPM engine, it contains all the above 
information. Since the sub-packet of the process data passed to the activity may be updated 
during task execution, it must be reconciled with the process data packet after returning 
However, before such a message is forwarded to a peer player, only the updated data elements 
that are shared with the player are retained (Recall that the sharing scope of each data dement is 
specfied in the process definition.) 

4.3 Queuing based Message Deliv ery Svn<Ar TO f»ti<wi 

A key design issue is to maintain the right order of message processing. For various reasons the 
messages may not be delivered in the original order. Refer to Figure 9 for the following scenario 
for example. 

(*) CjM A lariated a process instance P Ai and then started executing the first task, 7>; 

(2) CPM;* informed CPM* to create and execute the peer process instance, P m soon after initiating P A ; 

y) Upon completion of T It A forwarded the task return message of T : to CPM B. 
A possible consequence caused by out-of-order message delivery is, when the task return 
message of T t reaches CPM B, the initiation of P B has not completed yet, thus there is no ground 
for processing the above message. 




totfaitpeerpffocm i 

CPM A ^SH'" _ 

(3) Task return mgg for 77 




Fignre 9; Task return message received from peer before the counterpart process instance ready 

As another example, consider the execution of a collaborative process with three peer instances 
run by CPMs A, 3 and C> responsible for tasks T h T 2 and 7> respectively. These tasks are to be 
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executed in the order Tj, T 2> T s . Please refer to Figure 10 for the following scenario. 

both^d ? ^ C?M 4 corapleted * A foTWflrd «l *e task return message of T h ms gl , to 

(2) Upon receipt o£rmgj 7 CPM B started executing task T$ 

(3) When ^ completed, -5 forwarded the task return message of T 2y msg 2 , to both A and C 

in flus scenario, a possible consequence caused by out-of-order message delivery is, when msn 
reached C, it hasn t received msgj. In this case, processing msg 2 at CPM C can lead to an 
inconsistent result. 



Task 7> 



Task 7) 



CI) m$g];iafikr 9 



earlier than mg£ 1 




C3) magi; task 7j complete 
Figure 10: Task return messages from peer CFMs received tit wrong order 

Queuing technique tod the knowledge drawn from process definitions are used to resolve the 
out-of-order message delivery problem. Each CPM has a queuing server, in additional to the 
regular message queue handler (Figure 11). This queuing server is workflow specific as it 
interfaces to the process definition handler and the process instance log handler, using process 
definitions and execution histories to make operational decisions. It also responds to CPM 
internal events such as process instance status changes. 



Procdef 



MeflgQg& to/otrt 

(JQEUQ 



\ 



handler 



Log 



£ - — - 



Message 
troosponer 



handler 




Message* tot* acted on 



Me&a^aes to be queued 
Figure 11; Queidng server of CPM 



The general functions of the queuing server include the following. 

• When a message is received, check if it is ready to be processed based on the process 
definition, execution history and queued messages, and if not, queue the message. In the 
above example, if msg 7 for task T 2 cannot be executed at CMP C since C hasn't received the 
task return message for task T h ?mgj is to be put in the queued first* 

♦ After a new message is processed, check if any queued message is ready to be processed as a 
result, and if there is, process it In the above example, assume that CPM C queued msg 2 for 
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task Tj since it did not receive the task return message, ms gl> for Tj Later, when mm was 
eventaally received, CPM C would process ms gI for Fj first, followed by processing msg 2 for 

taS.cC ±2* 

When a CPM internal event about process instance status change (e.g. started, terminated, 
suspended) is received, the queuing server check if the change makes any queued message 
ready to be processed. In the example shown in Figure 8, assume mat the task return message 
for T, was queued as a result of the linavailability of P B , upon receipt of the event on P B 'a 
availability, the queuing server enables the processing of that message. 



Archltectui 



We have implemented CPM and integrated it into a dynamio software agent platform, E-Qury 
that we have developed at HP Labs. This novel integration achieves two purposes: on the one ' 
hand, it provides an implementation and execution platform for a CPM system; on the other 
hand, it elevates multi-agent cooperation in E-Carry from the conversation level to the process 
level for mediating e-Commerce applications. In addition, we have also integrated E-Carry with 
E-speak, an inter-enterprise communication infrastructure, to provide for inter-domain 
communication for inter-enterprise business processes. In this section, we briefly describe the 
mtegraaon of CPM, E-Carry, and E-Speak. Section 5. 1 describes me integration of CPM and E- 
Carry. Section 5.2 describes the integration of the agent-embedded CPM with E-Speak. Section 
5.3 discusses how this implementation architecture also serves the dual purpose of elevating 
mult-agent cooperation from the conversation level to the process level. 

S.l Agent Embedded ^TPM 

E-Carry is a dynamic and scalable platform for developing agent-based applications [6] Every 
E-Cariy agent contains a built-in Service Tier. The Service Tier of an E-Cany agent has the 
ability to load applications dynamically and to communicate with other E-Cariy agents in the 
same domain, ie., within a domain, E-Cairy ageots sharing the same Coordinator, hi addition, 
the service tier contains an embedded Web server with servelet functionality, enabling the state 
of an E-Carry agent to be accessed through a browser. The development of E-Carry is motivated 
by providing a migration from the traditional agent infrastructure to a scalable, dynamic and 
distributed middleware framework. 



ApplkidOd Tier I 




AttiEGstianller' 



Messaging Tier j 
E-C wry Agent A 




MVesagfng Tier 



E-Caury Agent B 



Figure 12: E-Carry agent with embedded CPM 



We have implemented the functionality of CPM and embedded into the service tier of E-Cany, 
as shown in the following figure. An agent with CPM embedded is used as a CPM server. 
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However, smce a CPM server can also be viewed as an agent, it is possible to consider the notion 
of personalized CPM engine. That is, each logical entity of an enterprise, say, a complementary 
product buying agent, could have its (or his) own CPM engine to represent it (or him) when 
participating in inter-enterprise collaboration, having its (or his) own CPM server executing peer 
process instances. Besides of acting as a CPM server, an E-Carry agent can also perform 
activities. The full details about E-Cany will be reported separately. 

Figure 12 shows agents with embedded CPMs. The CPM embedded in an E-Carry agent 
interacts with the hosting agent though a set of internal messages. The communication between 
agents is made through inter-agent message exchange. A set of agent messages specific to 
collaborative process management, are defined, and a corresponding message interpreter is 
provided for each agent. The E-Carry agent has the capability to load and switch interpreters 
based on message ontology types thus can easily handle applications in different contexts. 

5.2 Inter-Enternrlne Agent Communication 

Agent in the same group, referred to as the agent domain, can communicate using the naming 
service provided by the coordinator of that domain. However, agents in different enterprises may 
not form a single agent domain. Instead, they need certain "service bus" to locate each other for 
peer-to-peer communication. Further, issues such as firewall, security, access control, and even 
billing, should be taken into account. We have adopted the HP E-Speak service bus, an interface 
based service provisioning and invocation framework with multiple interconnected E-Speak 
Cores. An E-Speak core provides a set of predefined and extensible infrastructure services 
including authentication, authorization, billing, etc. These infrastructure services represent the 
major difference between E-Speak and the traditional CORBA-like middleware. In this paper we 
do not intend to explain E-Speak in detail. 

Intuitively, any agent, A, can register a "send message" service with E-Speak, making it possible 
for another agent in a foreign domain to directly invoke this service and thus able to directly send 
a message to A. However, if every agent has to register a messaging service in order to receive 
messages, and every agent has to maintain multiple client side messaging service 
implementations of all the agents it may need to have a contact with, it is not scalable. 

In order to unify the messaging interface for mter-enterprise agent communication, we only 
register the messaging service of the coordinator of an agent domain with E-Speak. This service 
then becomes the single entrance to the agent domain. Inside the domain, the coordinator can 
forward messages to other agents through intra-domain agent communication. Thus, it is 
unnecessary for each agent to register an individual message service, and the coordinator 
provides a gateway for any foreign agent to reach that agent-domain. On the other hand, every E 
-Carry agent only needs to be provided with a "standard" interface and the client-side stub for 
invoking the above messaging service, using the agent domain name as a parameter. By invoking 
the message service of an agent domain, an agent can contact any agent in that domain, with 
messages routed by the coordinator of that domain. 
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Domain: Buyer 

® © 

coordinator^ 




coordinator 



FJgore KiUntfr messaging service interface t° simplify inisr-vxterprUe a & em communication 

This mechanism is actually transparent at the message level, m an infra-domain message, the 
de 8 tinmioii m simply expressed by the receiver's name. In an inter-domain message, it is 
express ©q oy 

BSpeak. m domain m jramc/agejj(_jtame 

Here espeak is used to identify the service bus, a concept at a higher- level than transport service 
Given a domain_name, the messaging service of the coordinator of that domain can be invoked, 
as the messaging gateway for contacting all the agents in that domain. The agent_,iame local to 
tne domain is then used by the coordinator to route messages to that agent Refer to Figure 13 
when agents sends a message to agent B in domain "Vendor" , the full address of B is 
espeak: Vendor /B, and the message is transferred through E-Spcak infrastructure to the 
coordinator of domain Vendor, then forwarded to B. 

f 

5.3 CPMi for Profn- Level Agent Cmroer^f frn 

The collaboration of multiple peer CPMs is analogous to multi-agent cooperation 
[1,6,18^023.24.29]. In fact, using agent technology to support E-Commerce automation is a 
promising direction [4,3,22,26^7,30]. However, the previous "proof-of-concept" efforts in agent 
platforms do not scale well in E-Commerce automation for the following two major reasons. 

• Most E-Commerce applications are based on inter-enterprise business partnership but the 
current mechanisms for multi-agent cooperation is based on intra-enterprise coordination, 
wititout addressing the issue of mtea>entarprise collaboration. The conventional group-based 
coordination cannot handle inter-enterprise agent cooperation, since agents across enterprise 
boundaries are unlikely to be organized into the same group and under a centralirod 
coordination. 

• m the conventional agent platforms, agents cooperate through message exchanges, or 
conversations [17,28,22]. However, many real applications include complex business 
processes with a number of concurrent, long-duration, nested tasks, which, are difficult to 
manage and trace through flat conversations. Instead, a more robust and scalable approach is 
to lift agent cooperation from the conversation level to the process leveL 

Turning agent cooperation from conversation-level to process-level is a natural and necessary 
move. In general, businesses collaborate by following certain rules, such as "if you send me a 
price request then I will send you a quote", and "if the quote I sent you is acceptable, then you 
will send me an order". These rules include sequences of steps, with some of those steps nested. 
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Such business collaboration usually involves multiple agents, each responsible for managing or 
performing certain tasks that contribute to the process. Adding a process-level coordination 
capability into agent-based systems is critical in enabling the latter to better tackle such 
applications. 

We have relied on the proposed approach to tackle these issues. The combination of E-Carcy and 
CPM allows us to scale agent cooperation from conversation level to process level, and from 
mtra-enterprise cooperation to inter-enterprise collaboration. 

6. Conclusions 

Focusing on inter-enterprise E-Commerce automation at business process level, we have 
developed the collaborative process manager (CPM) to support peer-to-peer process 
management We further embedded CPM into a dynamic software agent architecture, E-Carry, 
that we developed at HP Labs* and extended E-Cany with the inteivdamain communication 
capability by utilizing inter-domain messaging services such as E-Speak and by introducing 
inter-domain messaging protocoL Through this work, we have made conceptual as well as 
practical contributions to both workflow technology and agent technology. 

Prom the workflow point of view, the proposed approach can be used to enhance the 
collaboration of business partners, and to support inter-enterprise business processes, a practical 
extension to the current workflow approach. 

From the multi-agent system point of view, the proposed approach can be used to lift agent 
cooperation from the conversation level to die process level, and from centralized coordination to 
peer-to-peer collaboration. The combination of CPM and agent ftamework can be a step towanis 
a scalable, dynamic, inter-enteiprise middleware fiamework. 

The feasibility of this approach has been demonstrated in a prototype implemented at HP Labs. 
We are currently investigating the use of this infrastructure to support CBL (Common Business 
Library)- and RosettaNet-baeed B-Commerce automation. 
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Using agent technology to support E Commerce automation is a promising 
direction. However, the previous "proof^concept* efrarte do hot scale well 
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We tackle the issue of scaling inter-enterprise agm* cooperation from the 
following three angle*. First, we have introduced the Point of Presence 
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interface-based service invocation. This approach aBowe us to unify the 
messaging service interface for all the agent*, and therefore greatly simplify 
both server-aide and client-side interface implementation and maintenance. 
Next, we have developed the agent-embedded cooperative process 
manager, for elevating multi-agent cooperation from the conversation level 
to the business process level, and from centralized proceae management to 
peer-to-peer cooperative process management Finally, we propose the 
conceptual separation of agent cooperation messaging network from 
the bulk data network. These emerging technologies are integrated with 
the ECarry agent infrastructure, an autonomous and decentralized system 
we developed at HP Labs. The feasibility of thia approach has been 
demonstrated in a prototyping system. 
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Abstract 

Using agent technology to support E-Commerce automation is a promiging direction. However, the 
Fwioiw -proof-of^oncept" efforts do not scale well is E-Cormnerce automation. An essentia] reason is 
Biat the conventional ageat infrastructures are primarily designed for itttra-entaprise, group-based agent 
cooperation, but moat E-Commerce applications ate based on inter-enterprise business partnership 
Agente across enterprise boundaries are unlikely to be organized into the same "agent group" and under a 
centralized coordination. 

We tackle the issue of scaling inter-enterprise agent cooperation from the following three angles. First, 
we have introduced the Point of Presence (POP) approach for integrating message-based agent 
communication wrth interface-based service invocation. This approach allows us to unify the messaging 
service mterface for all the agents, and therefore greatly simplify bom server-side and client-side interface 
implementation and maintenance. Next, we have developed the agent-embedded cooperative process 
manager, for elevating muln-agent cooperation from the conversation level to the business process level, 
and tremcentraliaed process management to peer-to-peer cooperative process management. Finally we 
pr^se Ow conceptual separation of agent cooperation messaging network from the bulk date 
network. These emerging technologies are integrated with the B-Carry agent infrastructure, an 
autonomous and decentralized system we developed at HP Labs. The feasibility of this approach have 
been demonstrated in a prototyping system. 

Keywords: Inter-Enterprise Agent Cooperation, Cooperative Business Process Management 

L From Intra-enrerartM. Agent reoper ation to Inter-enterprise Agent CorniM-ation 

E-Commerce applications operate in a distributed environment involving multiple parties with 
dynamic availability, and a large number of heterogeneous information sources with evolving 
contents. A business partnership is often created dynamically and maintained only for the 
required duration such as a single transaction. E-commerce activities typically rely on distributed 
and autonomous tasks for dealing with such operational dynamics. Today, they arc initiated and 
executed primarily by humans. With the goal of automation, conducting them by software agents 
has being proposed [3,4, 1 9,2 1]. However, the previous "proof-of-concept" efforts do not scale 
well in real E-Commerce applications. 
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Software agents have been studied for many years from all the aspects of software engineering- 
n f?J 1 ^ teCtUre [ 1 ' 5 > 6 » 22 > 23 ' 27 X communication language (e.g. ACL, K.QML 
112,17,20]), agent coordination, conversation management (e.g. FBPA specification [13]), etc 
However, previously agent technology primarily focused on autonomy, intelligence, ontolog^ 
Umguage, etc, but rarely on scalability. To our knowledge, there is no sizable, inter-enterprise E- 
Cotnmerce application using a commercial agent system ever deployed. It is time to examine the 
potential reasons for such a slow adoption. 

1 - 1 Agent Cooperation across Enterpr ise Bonnrtfl r »«"' 

Interaet-based E-Commerce involves multiple enterprises separated by firewalls. One difficulty 
tor me traditional agent technology to fit into this picture consists in the limitation of agent 
coordination model Such a model assumes that agents are formed in groups, or domains, each 
group is provided with a coordinator for facilitating naming service, resource service etc 
Agents in a group rely on these services to communicate and cooperate. While it is possible for 
tie agents belonging to the same enterprise, it is unlikely for the agents belonging to different 
enterprises, to fonn a single agent group, or domain. We see for example, a buyer agent for a 
retailer and a seller agent for a supplier might not be in the same agent group or under the same 
coordination (Figure 1). Organizing agent groups into a hierarchy may help, but does not 
eliminate the difficulty of coordination across enterprise boundaries. 

EategnwA: Buyer BatapriseB: 





Flifc- walls 



Figure 1: Group-based coordination does not support inttr-enterprise agent cooperation 

One possible solution is to use a CORBA-like service bus [8] for agents to locate each other in 
peer-to-peer communications. Intuitively, any agent, A, can register a "send-message* service, 
making it possible for another agent in a foreign domain to send a message to A, using mat 
service. However, if every agent has to register a messaging service in order to receive 
messages, and every agent has to maintain multiple client side messaging service 
implementations for all the agents it may need to have a contact with, it is not scalable. We call 
this "interface complexity" problem. 

leratton at Business Process Level 

Next, agents cooperate through message exchanges, and this has led to a research topic: 
conversation management However, many E-Commerce applications include complex business 
processes with a large number of concurrent, long-duration, long-waiting and nested tasks, and 
the flat conversation management lacks the scalability for handling and tracking such sizable 
applications. Instead, a more robust and scalable approach is to lift agent cooperation from the 
conversation level to the process level. 

Conventionally, a workflow engine is used to provide a centralized scheduling, monitoring and 
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f™ ceases ' 4e tasks that contribute to a process can be 

sS 25i£5S?JIf 15,18>2 5 ] ' ^ ^esa contxol Is appropriate within a 

Sl fi ^^T f 01 T 033 eateipnae boundari « s - Tntra-enterprise process management 
differs fiom Mtra-enterprfsepncess management significantly. Different enterprises are often 
sepanrtedby firewalls, have self-interests and individual data sharing scopes, ^i th^a^ 

S^a^T"" P i° CeSS ' ^ 816 totrustaEd «*> on a cilkd workflow 

^ ^15 /' ^ n ^. d * Upport for P^-to-Peer interactions [25 j . This has become the major 
mipendence for using the conventional centralized workflow systems for inter-enterprise E- 
Commerce automation. In fact, to our knowledge, there has been no such experience reported. 

cenfwliwd wmbtiew oigine 





2: Centralised wortyow control not suitable for cress-enterprise applications 

^change 



1.3 Agent Cooperi 

As Personalized, continuously running and semi-autonomous computational entities, software 
agents can be used to mediate user* and servers to automate a number of time-consuming tasks 
in B^ommerce. However, agents communicate by exchanging messages, which may not be 
suitable for bulk data transfer. Routing and caching a large amount of data also impose a 
considerable burden for agents. For example, as sown in Figure 3, moving date between an 
operational database and a data warehouse via a software agent is unlikely. 




Figure 3: Agents jbr mediating E-Commerce automation may not for bulk data transfer 



A principle of business process management is the separation of tasks from me processes they 
contribute to, in the sense that a task does not necessarily know the entire process. Analogously 
we can place bulk data transferring and agent cooperation at different conceptual layers, and we 
believe that is a necessary approach to scaling agent mediated ^Commerce automation. 

1.4 Onr Solutions 

We envisage that the scalability issues introduced above are critical to agent-mediated E- 
Commerce automation, and these issues are inter-related. We tackle them by the following 
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approaches. 

• We have developed the Point of Presence (POP) approach that supports inter-enterprise 
agentcommumcation using a CORBA-like service bus, HP E-Speak [1 1], but provides a 
united messaging interface to overcome the "interface complexity" problem. The use of fl- 
ap eak allows agents to communicate across enterprise boundaries, with fine-grained access 
control, firewall traversal and other infrastructure services. Under the proposed POP 
mechanism, each agent domain only registers the messaging service of the domain 
coordinator with E-Speak. This servico then becomes the single gateway to the agent 
domain, and can be made standard tor all the agent domains. Within a domain, the domain 
coordinator can forward messages to other agents through intra-domain agent 
communication. Thus on one hand, it is unnecessary for each agent to register an individual 
message service for receiving messages; on the other hand, an agent only needs a "standard" 
client-side rolerfece tor invoking the above messaging service to contact any agent in any 
foreign domain, using the domain name as a parameter. 

• We have introduced the notion of cooperative business process and developed agent- 
embedded Cooperative Process Managers (CPMs), which elevates agent cooperation from 
the conversation-level to the process-level, and torn centralized process management to 
cooperative process management with peer-to-peer interoperations. A cooperative business 
process is defined based on a commonly agreed operational protocol, such as me protocol for 
on-Une purchase or auction. However, it is not executed by a centralized workflow engine 
but by multiple agents with CPMs collaboratively. More specifioally, each execution of a 
cooperative process, or a logical process instance, consists of a set of peer process instances 
ran by the CPMs of participating agents. These peer instances share the same process 
definition, but may have private process data and sub-processes. The CPM of each agent is 
used to schedule, dispatch and control the tasks that agent is responsible for, and the CPMs 
intemperate through an inter-CPM messaging protocol to synchronize their progress in 
process execution. An XML-based Cooperative Process Definition Language, CPDL, 
extending the process definition language (PDL) [26], is developed fox specifying 
cooperative business processes. This approach represents a technical emerging of, and 
significant extensions to both workflow technology and agent technology. 

• We have developed the notion of niw-rier agent cooperation infrastructure that is 
characterized by the conceptual separation of cooperation message network and bulk data 
network. This notion is analogous to the separation of signal network and voice trunks in 
modem telephone infrastructure, where the former is used for routing calls, setting-up and 
tearing-down connections, and the latter for "transferring voice data. In our two-tier agent 
cooperation infrastructure, the message network is used for agents to exchange control 
information, meta-data and small size documents [10], and in addition, for setting-up and 
tearing-down connections between devices. The communication at this tier is message-based, 
asynchronized. Bulk data network is used for transferring large amount of data. The 
communication at this tier is generally synchronized. 

The approaches proposed above are related. For example, peer-to-peer cooperative process 
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management requires inter-enterprise agent communication; the separation of cooperation 
messages and bulk data transfers ensures the required data throughput in agent-mediated E- 
Commerce applications, and allows the control information and data of business processes to be 
handled separately, for both efficiency and privacy. 

Although the proposed mechanisms are independent of the underlying agent infrastructure, our 
experience has shown that implementing them using the E-Catry agent infrastructure, an 
autonomous and decentralized system we have developed at HP Labs, has many advantages due 
to its openness, scalability and flexibility. An B-Carry agent has the ability to load, maintain and 
start servers and applications dynamically. It also contains an embedded Web server with 
servelet functionality, enabling its state to be accessed or updated through a browser. Adding the 
proposed capabilities allows us to provide a migration from the traditional agent infrastructure to 
a dynamic and distributed middleware framework. The full details about E-Carry architecture 
will be reported separately. 

ItHPLate CanCe feasibUity ofthis wwk been demonstrated in a prototype implemented 

Section 2 describes the POP approach for using E-Speak infrastructure to support inter-enterprise 
agent cooperation. Section 3 discusses peer-to-peer, agent cooperative process management 
Section 4 illustrates the architecture for separating agent cooperation message network and bulk 
data network. Related work will be covered in Section 5 with conclusions. 

ter-Enterprise Agent rnnnnnnlcation with Unified M« B «nriiw Tnterfag* 

Agents in the same group, referred to as the agent domain, can communicate using the tunning 
service provided by the coordinator of that domain. However, agents in different enterprises may 
not form a single agent domain. Instead, they need certain "service bus" to locate each other for 
peer-to-peer communication. Further, issues such as firewall, security, access control, and even 
billing, should be taken into account. We have adopted the HP E-Speak service bus, an interface 
based service provisioning and invocation framework with multiple interconnected E-Speak 
Cores An E-Speak core provides a set of predefined and extensible infrastructure services 
including authentication, authorization, billing, etc. These infrastructure services represent the 
major difference between E-Speak and the traditional CORBA-like middleware. In this paper we 
do not intend to explain E-Speak in detail. 

Conceptually, an agent, A, can register a "send message" service with E-Speak, making it 
possible for another agent in a foreign domain to send a message to A by invoking this service. 
In doing go, however, we want to avoid the following possible problems. 

The first problem is the "interface diversity" problem we mentioned earlier, mat is, if every agent 
has to register a messaging service in order to receive messages, and every agent has to 
implement and maintain multiple client side messaging service interfaces for all the agents it 
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^t^^'nol ^ Tu*^ oncc » a « BBt cm « domain, it should be allowed to 
invoke certain services earned by the coordinator or other agents of that domain. If all those 
s ervices must be registered, it is not scalable from service invocation point ofview. 

2.1 Infer-domain Agent Communicati on with Unffied MmsbpW Tnterfr ra 

10 ^ *e»«»ftgnig interface for inter-enterprise agent communication, we integrate 
E-Carry and E-Speak in the following way. 






Enterprise A Domain 






Other service 




Mces aging 
«fsvioe 




coordinator 
Rrrtffip ri8& B Domain Dj 



Figure 4:tti{# „, essagtng service Interface to aimplffr inter-enterprise agent communication 

The coordinator^ of every agent domain carries ft messaging service, and registers this service 

£ ; S ? C ! k -^ servioe ^ *>«°°»» the single entrance to the agent domain. We refer to it 
as the Point of Presence (POP). Inside the domain, the coordinator can forward mesLes to 
other agents. Thus, it 13 unnecessary for each agent to register an individual message service, 
since ^coordinator provides a gateway for any foreign agent to reach any agent in that agent- 
o^mam. Further, services provided either by the coordinator or by other agents in that domain, 
may be invoked through messages. This also eliminates the need of registering every individual 
service, mamtaming therefore the single POP for service invocation as well (note that, however 
tnere is no restriction on service registration, i.e. open more POPs, as needed). ' 

Registering only the general messaging service also simplifies and unifies the client interface for 
sending messages. Every E -Carry agent only needs to be provided with a "standard" client-side 
stub tor invoking the above messaging service, with the domain name encapsulated in the 
message envelop. By invoking this message service, the agent can contact any agent in any 
foreign domain, with messages routed by the coordinator of that domain 



Through the messages an agent sends to a foreign domain, services provided by the agents 
(including the coordinator) of that domain can be invoiced, and such invocation is message-based 
without keeping continuous connection. Below we give some details about die 
used for inter-enterprise agent communication. 



messaging service 



At "server.side", the messaging service provided by the coordinator of en agent domain, D, 
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registered with E-Speak. The interface of this service includes a single method 

. void sendMsg(String message) 

The intake iiame, say AgentMsgService, phis a property "description" indicating the domain 
**Z' ™>TZ ,deQtlfy ^ * « i»^main message,^ destination i ZpT 

expressed by the receiver s name. In an inter-domain message, Hie destination is expressed by 

ouf^Sf ^? ^ £!? ""F 8 hi « hCT - IeveI **» t«^Port For example, whea 
our approach is extended to use http as the service bus, the logical address of an agent should be 

In thfecase the Web server embedded in an E-Carry agent will be used On the "client-side", a 
standard unplementrtum of the above interface is embedded to each E-Carry agent, as the 
speak message dispatcher". * 

ft^^Jin" 6 ?' f ° T ? aD L ple ' ^ hen ^^'^ domai » Z>, attempts to contact agent B 2 in a 
tarwgn domam D 3 , Aj invokes function sendMsg, that is registered with E-Speak by the 
coordinator of domain D 2 as ^ y 

Name— 'AgentMsgService 'and Description 

to U^T^ destination The message is first received by the 

^ TT a ^ r ° f D * • and J tbai foiwarded to ^ by the coordinator. At the first step, the E-Speak 
mfh«bT«aure service . fe called; at the second step, the local naming service provided by Sie 

fZZ.Sf^i U empl0> ? A inten * <« ^e a service provided bythT 

«»rdinator or another agent of A, the result of that service will be sent back to it via E-Speak as 



2.2 Messa ge Subacrihing/Pphliyl^ ng 
With E-Speak, agente from different 



_J 




♦Jill 






It 





» buy some electronic parts, instead of checking th 
"*^. lB *"■» °y ODS > » can puouan an avdlabOity-check message, and E-Speak can 
broadcast mi* message to all the vendor agents who subscribe this message. 

The message puhliah server carried by an E-Carry agent and registered with E-Speak, 
implemcntethe same interface as AgentMsgService, with a single method sendMsgKtrinz 
message) The agent represents a virtual agent domain: MsgPubHsher (Figure 5). Therefore 
when an E-Carry agent tries to publish a message, it sends the message to the MssPubUsher 
server, using espeak.MsgPubUsher as the address, just like sending a message to an aeent 

f^T" I° Sub3Cnbe to mcssa B e AvailabilityChedc, for instance, the subscribing agent should 
send the following message to espeak;AgentMsgPubllsher. 

<>A{ESSAGI> <MESSAGJUfAME> AvallnbitityChsck <AfESSA GE_ffAME> . . . <A?ONTENT> 
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KgureS: Publishing / Subscribing based communication 



2.3 Message-based. A synchronous Service Invocation 

The POP approach has an additional advantage when used for agent service invocation, that is to 
keep the message-based, asynchronous client-server communication. 

E-Commerce is uptug and play environment. Services need to be provided on demand Business 
partnerships (e.g« between suppliers, resellers, brokers, and customers) need to be created 
dynamically and maintained only for the required duration such as a single transactional process. 
To support such dynamics, an E-Conunerce infrastructure must support the cooperation of 
loosely coupled e-business systems* 

Interface oriented, CORBA-like middleware is based on a technology for integrating tightly 
coupled local systems. It doesn* fit into the picture of ^business since it is too dependent on 
Remote Procedure Call (RPC), or Remote Method Invocation (RMI), a form of synchronous 
communications in which networked devices maintain continuous contact. Synchronous 
communications lack the flexibility for plug-and~play e-business, and dou* cope well with 
firewalls. In the contrary, Web-based communication is asynchronous, where a message is sent 
when the line is available and contact is interruptible. This feature is also represented by IBM% 
MQ Series and Microsoft^ MSMQ messaging middleware. 

The E-Cany capability for carrying actions allows a domain coordinator to cany multiple 
services not registered with E-Speak, but invoked through messages. Services carried by other 
agents in the domain can also be invoked on the message basis. It is unnecessary (but optional) to 
register agent provided services with E-Speak, Una well fits in agent cooperation where most of 
the services are kept message-enabled. 

3. Inter-Enterorfae. Peer-to-Peer A gent Cooperation at Business Process Lavfel 

Many E -Commerce applications include complex business processes, and involve multiple 
enterprises. To handle such applications through simple agent conversation is not scalable, and 
through a centralized server is unreasonable. This has motivated us to lift agent cooperation from 
the conversation level to the process level, and from centralized process management to peer-to- 
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peer cooperative process management. 

3.1 From Centralized process Mana g ement to Cooperative l>rocesa Managft ngnt 

A business process specifies the integration and synchronization of multiple steps, each step 
represents a logical piece of work that contributes to the accomplishment of the whole process 
Although these tasks and the agents executing them can be distributed, they are scheduled and 
coordinated by a centralized workflow engine. Typically a business process includes a data 
packet containing ih$ process data for control flow and data flow, and tasks can manipulate the 
process state by updating these data. However, consider a purchase process involving tasks 
belonging to different enterprises, e.g. the buyer and the seller. It is unrealistic to have the buyer 
and the seller coordinated by a single workflow engine, and it is unreasonable for them to put 
their private data (e.g, negotiation thresholds) into the common process data packet for flow 
control. 

Our solution to the above problem is based on extending process management fium the one- 
server model to the multi-server peer-to-peer modd, a shift from centralized process 
management to cooperative process management. 



We introduce the notion of cooperative business process. An inter-enterprise cooperative 
process involves multiple parties. It is defined based on the corresponding business protocols, 
and such a definition becomes the common template for all the participating parties to share, ' 
However, an execution of a cooperative process, viewed as a logical instance of the process, 
actually includes multiple peer instances that are not executed by a centralized workflow engii 
but by multiple CPMs and synchronized through peer-to-peer communication. These peer 
instances share the same process definition, but may have private process data and sub- 
processes. The CPM at each side recognizes its own share of the tasks (shaded in Figure 6) 
based on role-matching. For example, an on-line trading process, say P, is executed 
collaboratively by a seller and a buyer in such a way that each peer CPM runs an individual 





Figure 6: Peer-to-peer coflvborattve proems management 
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process i instance of P. For the CPM at buyer side, it is only responsible for (schedule and 
dispatch) the testes to be executed by the buyer, such as preparing a purchase order and making a 
payment Similarly the CPM at seller aide is only responsible for the tasks belonging to the 
setter. The CPMs exchange task execution status messages for synchronization. 

3.2 Agent Embedded Cooperative Process Manarer 



We have implemented CPM and integrated it into E-Carry agent platform. This novel integration 
achieves i two purposes: on the one hand, it provides an implementation and execution platform 
tor a CPM system; on the other hand, it elevates multi-agent cooperation in E-Carry from the 
conversation level to the process level for mediating B-Commerce applications. 



Application Tier 




AjqilicatiDJi Tier 



Messaging Tier 



K-Canry Agtat A 




E-Carry Agon B 



Figure 7: E-Carry agmt with embedded CPM 



** anown in figure 7, the functionality of CPM is embedded into the service tier of E-Carry 
The agent with CPM embedded can then be used as a CPM server. Since a CPM server can also 
be viewed as an agent, it is possible to consider the notion of personalized CPM engine That is, 
each logical entity of an enterprise, say, an electronic parts buying agent, could have its (or his) 
own CPM engine to represent it (or him). When participating in inter-enterprise collaboration, it 
Has its (or his) own CPM server executing peer process instances. Besides of acting as a CPM 
server, an E-Carry agent can also perform activities. 

The CPM embedded in an E-Carry agent interacts with the hosting agent though a set of internal 
messages. The communication between agents is made through inter-agent message exchange. A 
set of agent messages specific to cooperative process management, are defined, and a 
corresponding message interpreter is provided for each agent. The E-Carry agent has the 
capability to load and switch interpreters based on message ontology types thus can easily handle 
applications in different contexts. 

33 Cooperative Pi-ncw m Definitio n 

To explain how the proposed cooperative process management approach extends the current 
workflow technology, we adopt the usual concepts of business process modeling in the following 
discussions. A process is modeled as a DAG with nodes representing the steps, or tasks, and arcs 
representing the links of those steps. A work-node represents a step {task) and associated with an 
activity, i.e. a piece of work that contributes to the accomplishment of the process, that may be 
executed either by a program (e.g. a software agent) or by a human worker. A process is 
associated with a packet of process data. When an activity is launched, a subset of the process 
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data, sub-packet, is passed to it; when it is completed, together with task status information, the 
sub-packet, possibly updated during the task execution, is sent back for reconciliation with the 
process data packet. A route-node specifies the rules and conditions for flow control, process 
data update, etc. Conventionally, a process execution creates a single process instance. However 
for a cooperative process, the logical instance of each execution includes multiple peer process ' 
instances. Farther, a cooperative process may have multiple concurrent executions. To support 
cooperative processes, the minimal extensions to process definition include the following. 

A cooperative process has a list of process-roles, indicating the logical participants. For 
example, if a simple purchase process has two roles, "buyer" and "seller", then there are two 
peer instances involved in its execution, one at the CPM for "buyer" and another at the CPM for 
"seller". These two peer instances are assigned roles "buyer" and "seller" respectively. 

A work-node has a task-role, and that must match one of the process-roles. In the above 
example, tasks can have roles "buyer" and "seller". If the role of a task is "buyer", it is only 
executed in the peer process instance with process-role "buyer". Note that an activity also has a 
role called activity-role, such as "invoice-generator", meaning that this task should be executed 
by (or dispatched to) an agent playing the "invoice-generator" role in this process. The notion of 
activity-role can be found in regular business process specifications. 

In an inter-enterprise cooperative process execution, each party wants to keep some of the 
process data private. For example, the buyer in one enterprise and the seller in another enterprise 
do not want to expose their thresholds during price negotiation. In the process definition, 
templates for holding the definitions and initial values of process data objects can be specified. 
F^ermore, the sharing scope of the data objects is specified A template may bo public, i.e. 
shamble by all process-roles (and thus by all peer process instances) or process-role specific. A 
role-specific template is used by the peer process instances of the given roles (one or more) 
only, and such templates can be made different for different process-roles. Consider a 
cooperative process with roles "buyer", "seller" and "bank"; some data are private to "buyer"- 
some are shareble by "buyer" and "seller"; some are public to all three roles. The initial data ' 
packet of a peer process instance consists of the appropriate templates, where die sharing scope 
of each data object is marked This data packet can be updated or expanded at run time. 

A task may represent a private sub-process with a private data packet The sub-process binding is 
dynamic, that is, hound at run time. This allows a private sub-process to be designed separately 
from the host process. The process data of the internal sub-process is entirely private to the party 
executing the sub-process. 

An XML[2]-based Cooperative Process Definition Language, CPDL, extending the process 
defioition language (PDL) by capturing the above notions, is developed for specifying 
cooperative business processes. 
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3.4 Cooperative Pro^s s Execnti 



rSiS^I? J cooperative process consists of a set of peer process instances run by the 
CTMs of the participate agents. These instances share the same process definition but they 
have additional properties and may have private process data and sub-processes. 

Each peer process instance has a role that must match one of the process-roles. When a neer 
ESSES - "?!" ™ hed b 7 8 Cp M ^ the seller side, for example, the process-in^tance-role 
ml i SS i^iSL 'I y res P oasib,e for Ruling and dispatching the tasks with task- 
™1 ^ lcf ■jr ieQ executing a cooperative business process, the player of each peer process 
mstocemustbe specified and bound to the corresponding process instance role. In addition, a 
lo&cai Identifier for this execution must be obtained. These pieces of information are captured as 
properties in every peer process instance. They are further described below. 

The player, of a cooperative process indicate the participating agents with embedded CPMs. A 
player is associated with four attributes. 

• The role, ».g. "buyer" or "seller", of the given process instance tumuflg at the CPM that represents 
fas player. Note that without binding to a peer procera-iostauce, a CPM does not have a fixed role 

• The domain name of the agent 

• The local name of the agent within the domain to represent the player. For example 

^SS£^SS^ M be - a , pl ? yer playin * ^ bu y er ■ a/w^rth* business proems, 
Whose peer agent in this process might be us.oracle.com/sa[es_j,geni. 

• The inter^omaiii messaging service infcistructure, such as HP E-Speak, that provides messagm? 
services i fbr mter-dcmain agent communication. The messaging service infruBtructure is capable of 
delivering messages among multiple domains. As mentioned above, when peer agents particiTiatinK a 
cooperative process execution rely on E-Speak to reach each other, the addressing structure is 

espeak:domaiii_jiame/!ocal _jmme. 

A coop-key is used to identify a logical instance of » cooperative process, that is, to correlate and 
synchronize nie multiple peer instances of the execution of a single cooperative process. All the 

£S8? T 0 ^! 8 ! ^ execution marked by a unique coop-key. In our implementation, 
the CPMof each E-Carry agent can run multiple process instances concurrently, and each 
instance has a local ID. Each CPM engine maintains a mapping table between coop-keys and 

«■ mstaJ f e ^ a message relating to the execution of a cooperative process is 

received, the coop-key is used to identify the corresponding local process instance. 

Let us use a simple example shown in Figure 8 for explanation purpose. The sample cooperative 
process for on-line purchase defined based on the OBI (Open Buying on Internet) protocol 
oh^process, has process-roles "buyer" and "seller". Each logical instance of obinrvcess has 
two peer-uistances run at two peer CPMs, A and B, one at the buyer side and one at the seller 
side. It has several tasks (steps) including T, (make purchase order), T 2 (process purchase order), 
etc. T, is a step the buyer is responsible for, so its role is "buyer", while the role of T 2 is "seller" 
A, running the peer instance with role "buyer", is responsible for executing T h and B, running the 
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peer instance with the role "seller", is responsible for executing T 2 , The initial data packet for 
procesa-role "buyer** and "seller" can be different The execution of a cooperative process is 
carried out in the following way: 

• C?MA t representing the process-instance-role of"buyer n , initiates a buyer-side process instance P b 
and through messaging, tells CPM B to create a seller-side peer process instance P s . 

• A dispatches and executes T u and upon receipt of the task return message, r l% forwards it to all other 
players of the process, in this case, simply B. Both .4 and 3 update their process state and schedule the 
possible next step of their own peer process instance based on that message, 

• When A proceed* to activity 7i, since the role represented by A does not match the role of A 
simply waits for the peer server, that is B in this example, to handle it at the peer site. ' 

• When B proceeds to activity T 2 , since the role represented by B matches that of T 2 > T 2 wfll be handled 
by 2J. 

• The execution of peer process instances at both peer CPMs progress in this way, towards their ends. 



Cooperative process role* task role task rote 
buyer, solta buyer roller 



• • 




mmm 





Btttfifpiiya 




Onvpmesa 

One logfeftl «i0c«Oon 
liurtaace 

A set of peer instftfttm 



Efflfifptisc 



Figure 8: Peer-to^peer collaborative process management 

An activity is dispatched to a software agent or a human user to perform, and upon its 
termination, a task return message is sent back and used to trigger the next step in process 
execution. Such a task return message contains the coop-key of the logical process instance, the 
handles (local Ida) of the process instance, task, and activity, the activity execution status, and the sub- 
packet, La the subset of process data passed to die activity. 

When a task return message comes back to the local CPM engine, it contains all the above 
information. Since the sub-packet of the process data passed to the activity may be updated 
during task execution, it must be reconciled with the process data packet after returning. 
However, before such a message is forwarded to a peer player, only the updated data elements 
that are shared with the player are retained. (Recall that the sharing scope of each data element i 
specified in the process definition,) 

A key design issue is to maintain the right order of message processing. For various reasons the 
messages may not be delivered in the original order. Queuing technique and the knowledge 
drawn from process definitions are used to resolve the out-of-order message delivery problem- 
Each CPM has a queuing server, in additional to the regular message queue handler. This 
queuing server is wortylow specific as it interfaces to the process definition handler and the 
process instance log handler, using process definitions and execution histories to make 
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operational decisions. When a message is received, the queue server checks if it is ready to be 
processed, if not, queue the message; and if it is, further checks if the change makes any queued 
message ready to be processed. It also responds to CPM internal events such as process instance 
status changes. 

Turning agent cooperation from conversation-level to process-level is a natural and necessary 
move. lu general businesses collaborate following certain rules, such as **i£ you send me a price 
request then I will send you a quote", and "if the quote I sent you is acceptable, then you will 
send me an order* 1 . These rules include sequences of steps to form a business process. Such 
business collaboration usually involves multiple agents, each responsible for managing or 
performing certain tasks that contribute to the process. Adding inter-enterprise cooperative 
process management capability into agent-based systems is critical for these business 
collaborations. 



4. Separating Bulk Data Tra nsfer from Agent Cooperation fl* es«*M 

In previous agent cooperation frameworks, there is no explicit separation of control information 
and application data agents exchange. A business process instance is also combined with control 
flow and data flow. In some workflow systems such as Lotus-Notes, control flow and data flow 
are fUlly combined. 

We have described early in this paper that for data privacy purpose, in cooperative process 
management we define the scopes of data visibility among peer CPMs and separate the non- 
sharable data from the shamble data. The messages for synchronizing cooperative process 
execution contain no sensitive private data, and data exchanges are handled at the task execution 
level, with explicit privacy control Here we revisit this issue beyond process management 

In agent cooperative activities, agents communicate by exchanging messages. The content of 
agent conversation may be requests, inter-CPM messages, or moderate size business documents. 
However, transfer bulk data via software agents is neither efficient nor necessary. It is inefficient 
since the data transfer throughput of software agents is far less than large-scale data servers. It is 
unnecessary since the percentage of control data (to be handled by an agent) in a large data 
stream is feirly small. This has led to the idea of separating bulk data network from agent 
cooperation message network conceptually. We believe this is the key to the success of agent 
mediated E-Commerce automation, although it requires substantial work in standardization. In 
fact, such a system configuration is analogous to a modern telephone system* 

In the telecommunication infrastructure, an important architecture feature is the separation of the 
voice network and the signal network. The voice trunks connect end-offices for voice data 
traffic* The end-offices are connected to and controlled by the SS7 signaling network (Figure 9) 
for switching, monitoring, traffic information gathering and so on. Such separation aims at 
enhancing the controlling and monitoring functionality over the whole infrastructure, With the 
separation of the signal network from the voice trucks, for example, the caller-id service can be 
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provided to allow a callee to know who the caller i 8t before picking up his phone. 




Figure 9: Telephone network: separation ofsignalnetwork from wlcefdata) trunks 

Our proposed infrastructure is illustrated in Figure 1 0, where bulk data transfer is separated from 
the agent Cooperative Message Network (CMN). As mentioned above, the CMN still can be 
used for agents to exchange moderate size data as message contents. However, large data transfer 
such as database loading, must be separated from agent message delivery. 

IE-Carry Collafonittoa Mnssgbig Network (CMN) 




Figure 10: Separate collaboration message network from Data Network (Paylaad) 

Wecan once again relate this concept to cooperative process management, where processes and 
taslcs are already separated into two system layers. Bulk data transfer can be handled at task level 
wijout via process level messaging. Such separation can be introduced to the general agent 
mediated E-Commerce automation, that is, separate the tasks involving bulk data transfer torn 
me cooperation activities between agents. For instance, with the servelet capability, E-Carry 
agents can respond to certain messages by setting up corresponding services, including enacting 
the actions to set-up or tear-down connections between the systems they represent For example 
an E-Carry agent can execute a program that starts an Oracle Express OLAP script for loading 
data into its multi-dimensional database from a relational database. 

S. Com parisons and Conclmrf^ 

We have developed several inter-enterprise agent cooperation approaches for supporting agent- 
mediated E-Commerce automation. These approaches represent an integrated solution based on 
emerging technologies and applications. The agent embedded CPMs enable peer-to-peer agent 
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cooperation at the business process level, and communicate using the unified messaging 
interface under the POP mechanism. This mechanism also supports message-based, 
asynchronous application invocation without requiring continuous connection. By separating 
bulk data transfer from cooperative message network, the data throughput limitation of scents 
can be overcome. 

Compared with the group and group-hierarchy based multi-agent systems [12-14,16], we scale 
agent cooperation across enterprise boundaries by supporting peer-to-peer, non-coordinated 
inter-domain communication and collaboration. 



Compared with RPC and RMI [8], the POP approach allows us to maintain, to the maximum the 
benefits of asynchronous communication for Internet based applications. The regular use of 
RPC/RMI based middleware is to specify a service function in an interface class. Although 
multiple functions may be grouped into a single interface class, conceptually every service 
function must bo specified and registered. In order to contact multiple interfaces, multiple client 
side implementations of those interfaces must be provided. Use this mechanism allows agents to 
reach out the local domains, but would require handling a lot of interfaces both for service 
provisioning and for service invocation. The proposed POP approach provides a unified interface 
forinter-domain agent commumcation, and therefore can reduce the above complexity. The use 
of E-Speak further offers the benefits of infrastructure services. 

Compared with agent conversation management [13], the use of CPMs allows ub to lift agent 
cooperation from the conversation level to the process level, and from centralized coordination to 
peer-to-peer collaboration. 

Compared with existing workflow systems [26], the proposed cooperative process management 
can be used to enhance the collaboration of business partners and support inter-enterprise 
business process executions. This represents a novel extension to the workflow technology. 

Compared with the conventional process federation and RosettaNet PIP approach [24], we 
conclude that our approach is capable of supporting PIPs. However* our approach goes beyond 
PIP in the following aspects. First, cooperative process management is based on process-level 
business protocols and PIP approach is based on interface tasks. PIPs expose individual "hand- 
shake" or conversation points of partner processes, but not a process level view to their 
cooperation. Second, we have a peer-to-peer execution model for cooperative processes but the 
PIP approach does not. m PIP approach, the execution of partner processes are not related and 
synchronized at process-level. Each parry sees the trees, not the forest. 

From the above comparison we can see the uniqueness of the proposed approaches in supporting 
inter-enterprise agent cooperation, the key to realize and scale agent-mediated E-Commerce 
automation. The significance and feasibility of this work has been demonstrated in a prototype 
implemented at HP Labs. We plan to further extend this system to a scalable, dynamic, inter- 
enterprise middleware framework. 
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